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14. Diagnostic Strategy 



Prepared By: Mary Ann Gallagher 



Diagnostic strategy for the Firefox system consists of three tiers of testing with a major objective of isolat- 
ing to a field replaceable unit (FRU) on failure. 

The first testing tier is a power-up self-test that covers all testable functions of the system, including all M- 
bus options and a denned set of Q-bus options. This test is a fast, efficient check for stuck-at faults, and it 
provides a high level of confidence that the system can boot. The PST runs automatically on system 
powerup; alternatively, it can be activated from the system console program. 

The second testing tier is a system test that covers all testable functions of the system, including all M-bus 
options and a defined set of Q-bus options. It extends the test coverage of the PST by providing coverage 
of intermittent faults and faults caused by module interactions. The system test differs from the PST in that 
it tests modules concurrently rather than one by one and is, therefore, a closer approximation of a real user 
environment. The system test is started from the system console program. 

The PST and system test will have three modes: customer, field service, and manufacturing, with different 
levels of test coverage and capabilities for each. The third testing tier is for utilities. Required utilities 
currently include NI loopback, DSSI utilities, and monitor patterns. These diagnostics will include detailed 
tests using loopback connectors, visual tests, and selective and continuous execution of tests. 

14.1. Description of Diagnostic Product 

The diagnostics product consists of the following components: 

• Power-up self-test 

• System test 

e System utilities 

Together, these components will provide a thorough check of the Firefox system. The primary purpose of 
the product will be to provide the end user, CSSE, Manufacturing, and Design Engineering with a set of 
comprehensive diagnostic tools. These tools will incorporate quality, low maintenance costs, and high reli- 
ability into the Firefox system. 
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Table 14-1 : Location of EPROM Code in Modules 



Module 


Code in EPROM 


Dual-CVAX Processor 


CPU PST, console code, primary 
processor determination, memory 
PST 


I/O 


PST, VMB, utilities, system test 
kernel, monitor and test modules 


Graphics 


PST, system test, utilities, console 
support code 


Q-Bus Adapter 


PST, system test, selected Q-bus 
option tests* 



* The assumption here is that a denned set of five Q-bus options 
will be tested under the Firefox system diagnostic strategy. 
The EPROM architecture allows for integration of add-ons to the 
diagnostics and can be used by the Laboratory Development Product 
Group for "DEC specials" or sold to OEMs who want to add their 
own Q-bus options. 



14.1.1. Power-Up Self-test 

The power-up self-test will reside in EPROM and be invoked on powerup, on reset, or by console com- 
mand. It will isolate the fault to the failing FRU, excluding unsupported Q-bus options. Errors will be 
reported via LEDs on the modules and via the console using numeric error codes. The PST for the CPU 
module will test each CVAX, CFPA, cache, and FBIC in parallel. When the CPUs are tested, a primary 
CPU will be determined, and it will test the other modules. Although the memory module has built-in 
self-test capabilities, the testing must be started, completed, and evaluated by the primary CPU. Worksta- 
tion I/O-module testing performed by the primary CPU will include tests for the FBIC, SSC, serial lines, 
disk/tape interfaces and network interface (NI). Tests for the Q-bus-adapter module will include FBIC, 
CQBIC, and the Firefox-supported Q-bus options, including the TKQ70, DRQ3B-AA, DRV11-SA, 
DZQ11-SA, andRRD50. 

/* 

14.1.2. System Test 

The system test will be used to provide the user with a high level of confidence that the Firefox system is 
functioning correctly. It is designed to detect stuck-at faults, intermittent faults, and system-related faults 
in the modules. The system test differs from the PST in that it tests modules concurrently rather than one 
by one. As a result, it is a closer approximation of a real user environment. It also allows for testing that 
would be inappropriate in the PST because of time limitations or other constraints. The system test is 
based on VAXELN, which provides a multitasking environment. The goal of this test is to migrate all cus- 
tomer and CSSE diagnostics into EPROM when they are stable. 

14.1.3. System Utilities 

System utilities complement the PST and system test by providing a mechanism for the user to use to detect 
and isolate faults that cannot be captured through software intervention. These utilities will be stored in 
EPROM on the I/O module and on the graphics module. Sample utilities in the I/O EPROM include the 
disk formatter and verifier and an Ethernet loopback responder. The graphics-option EPROM will contain 
monitor test-pattern utilities. 
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14.1.4. Network Management Interface 

To meet the diagnostic requirements of a distributed system, the Firefox diagnostics will be designed to 
interface to the Network Management layer of the Management Control Center (MCC), which is being 
developed by the Network and Communications group. The functions provided are expected to be network 
reporting of configuration and self-test results, but this is dependent on the availability of specifications 
from the MCC developers. 

14.2. Goals 

The following have been earmarked as diagnostic goals: 

• To develop a concise, thorough PST with 97 percent failure isolation to the FRU 

• To exercise the system concurrently to detect system-related faults, stuck-at faults, intermittent 
faults, and reliability failures with system test, with 97 percent failure isolation to the FRU 

• To provide CSSE with a set of diagnostic tools that are effective enough to give 97 percent isolation 
of faults to the failing FRU and to ensure that FRUs need never be swapped at random 

• To work with NAC to integrate the Product Diagnostic System with the Network Fault Management 
tools (that is, to provide the ability to report configuration and status through the NI) 

The different diagnostics should complement each other to provide maximum coverage and fault isolation. 
Table 14-2 summarizes the fault coverage goals for the different modes and tests. 

Table 14-2: Fault Coverage Goals 



Test 




Mode 






Manufacturing 


CSSE 


Customer 


PST 


90% 


90% 


80% 


PST + 

System test 


95% 


95% 


85% 


PST + 

System test + 
Utilities 


97% 


97% 


90% 



14.3. Nongoals 

• PST will not provide intermittent-fault detection, although loop-on test capabilities will be included. 

• Fault isolation to the chip level is not a goal, although fault-isolation information will be as detailed 
as possible. 

• Extensive fault insertion to evaluate product quality is a nongoal for diagnostics. However, diag- 
nostics will help system test engineers and product assurance develop a fault-insertion test plan as 
pan of the DVT. 



14.4. Operating Environments 

The PST is run automatically at powerup, or when a TEST command and parameters are entered in console 
mode. In CSSE or manufacturing mode, parameters specified allow the user to execute a specific func- 
tional test, to execute the entire PST, loop-on test, and/or loop-on error. Errors are reported on the desig- 
nated console device and through LEDs. 

The system test is run when a TEST command and parameters are entered in console mode. In CSSE or 
manufacturing mode, parameters specified allow the user to execute a specific functional test, to execute 
the entire system test, and/or loop-on test. Errors are reported on the designated console device and 
through LEDs. 
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14.5. Related Documents 

For a more detailed description of the Firefox diagnostics, see the Firefox Diagnostic Project Plan. 
For a more detailed description of the Firefox graphics option diagnostics, see the LEGSS Diagnostic Pro- 
ject Plan. 



4 Firefox System Specification December 23, 1987 Diagnostic Strategy 14.5. 



